When two computing devices need to communicate over an insecure link such as a Wi-Fi or Bluetooth connection, it is often desirable to verify that each device is talking directly to the other—that is, there is no “man in the middle” intercepting messages and masquerading as each device to the other. Even where such communications are encrypted, if the two devices have not previously been connected securely, there must be an initial phase wherein the devices exchange encryption keys or other tokens so that they can then verify each other's identities in subsequent communication. However, if the “man in the middle” can also intercept that initial exchange, then the key-exchange step becomes useless.
For this reason, “pairing” processes between two devices often include a separate “out-of-band” verification step, wherein the devices ask the user to perform some action on both sides of the communication. With this approach, the user acts as a secondary channel for the devices to verify that they are talking directly to each other, making it much harder for a third party to interpose itself into the devices' main communication channel. This process often relies on Diffie-Hellman key exchange, which is a way for two parties (in this case, the pairing devices) to generate a shared secret by exchanging information over an insecure channel. If a third party is intercepting the communications and acting as a man-in-the-middle, the secret generated by the two original parties will differ, and comparison of these two secrets over another channel, e.g. the user, will expose the discrepancy and thereby reveal that the first channel is compromised. The most common approach for this verification—used with many Bluetooth peripherals, as well as in iTunes's® Remote functionality—is to display a numeric code, either (1) on both devices, in which case the user is asked to verify that the codes match, or (2) on only one of the devices, in which case the user is asked to enter an identical code on the other.